Summary

Changes these settings from "scope": "machine" to "scope": "application" (all keep ignoreSync: true, so Settings Sync behavior is unchanged):

• coder.binarySource
• coder.binaryDestination
• coder.headerCommand
• coder.tlsCertFile
• coder.tlsKeyFile
• coder.tlsCaFile
• coder.tlsAltHost
• coder.tlsCertRefreshCommand
• coder.proxyLogDirectory
• coder.proxyBypass (deprecated in favor of http.noProxy)
• coder.sshConfig
• coder.sshFlags
• coder.globalFlags

Only the local-vs-remote read scope changes; sync behavior stays exactly as before. (We considered opting a few non-path settings into sync now that they are application-scoped, but held off: a download URL, a TLS hostname, a no_proxy list, or CLI flags can still be machine- or network-specific, and that is a separate decision from this fix.)

Why

machine scope was introduced in #965 (SEC-200) to stop workspace and folder settings.json from overriding these settings. application scope preserves that goal: it can only be set in User settings, never overridden by workspace or folder settings.

But machine scope also makes VS Code stop honoring the User-configured value in a remote window. Reporters in #1032 saw the first connection work and later connections fail with no settings change; two independent users confirmed an application-scope build fixes it on Windows 11 and pinned the regression to v1.14.6, the release that shipped #965. All these settings are read at the same pre-connection point (right before SSH connects), so they share the exposure. Array settings (sshFlags/globalFlags) behave like the string ones, since scope resolution is per-key regardless of value type.

The VS Code mechanism

In a remote window, WorkspaceService filters the local user configuration through LOCAL_MACHINE_SCOPES = [APPLICATION, WINDOW, RESOURCE, LANGUAGE_OVERRIDABLE] (getLocalUserConfigurationScopes in configurationService.ts), which excludes MACHINE (see configuration.ts). A machine-scoped value can then only come from the remote machine's settings file, not the local one where the user set it. This is deliberate, long-standing design:

• microsoft/vscode-remote-release#2: "machine settings scoped to a machine ... it makes sense to not to respect local machine settings configured in user settings in a remote window."
• microsoft/vscode#177502: the VS Code team hit this for a resolver reading http.proxy and fixed it the same way we do here: "Made proxy settings application scope by default. Once connected to remote, scope is changed accordingly."
• configurationService.test.ts > machine settings in local user settings does not override defaults: writes a machine-scoped key to the local user settings.json, constructs WorkspaceService with a remoteAuthority, and asserts getValue() returns the default.

Reproduction (the "sometimes")

That unit test drops the value on a single connect because the schema is already registered when WorkspaceService is built. At runtime the extension registers its schema during activation, after the window's first parse, so the outcome is timing-dependent. The deciding logic is shouldInclude (configurationModels.ts): an unregistered key (scope undefined) is kept, while a machine-registered key is dropped under LOCAL_MACHINE_SCOPES.

1. The remote window opens and parses settings.json before the extension activates, so the key is unregistered and kept.
2. The extension activates (onResolveRemoteAuthority) and registers its machine-scoped schema.
3. The next re-parse of settings.json (an edit, a Settings Sync write, a profile switch, or a tasks.json load) re-applies the filter, now sees MACHINE, and drops the key to its default. There is no remote fallback.

Reproduced with a source build of VS Code and a minimal UI extension (scopetest.machineSetting, scope: machine) on an SSH remote, with local settings "scopetest.machineSetting": "value-from-USER-settings" and no remote fallback. Editing settings.json after activation flips the resolved value:

shouldInclude logged the deciding step at each parse (scopes is LOCAL_MACHINE_SCOPES = [1,4,5,6], no MACHINE):

shouldInclude key=scopetest.machineSetting propertySchema.scope=undefined options.scopes=[1,4,5,6]  -> included
shouldInclude key=scopetest.machineSetting propertySchema.scope=2         options.scopes=[1,4,5,6]  -> excluded

APPLICATION (1) is in LOCAL_MACHINE_SCOPES, so an application-scoped key is honored regardless of timing. That is the fix.

This PR and investigation were assisted by Coder Agents on behalf of @EhabY.